Ethan's Notes

Appearance

Spring AI 与 RAG 集成 ​

1. 通用思想：它在 Agent 里是什么？ ​

RAG 解决的是：模型知识老、看不到企业私域数据、面对长文档和实时规则容易幻觉。对 Agent 来说，RAG 不是“多检索一点资料”，而是把外部知识在正确时机注入到本轮推理里。

所以从通用思想上看，RAG 是 Agent 的知识补给层：

  • 用户问题进来
  • 系统判断是否需要外部知识
  • 检索相关文档
  • 把高价值证据注入模型
  • 模型基于这些外部证据回答

真正关键的不只是检索本身，而是检索前、检索后、上下文注入方式和噪声控制。

2. Spring AI 落点：由哪些抽象和链路承载？ ​

核心抽象 ​

  • VectorStore：向量数据库抽象层，屏蔽底层实现差异
  • QuestionAnswerAdvisor：官方的轻量级 Naive RAG 入口
  • RetrievalAugmentationAdvisor：更完整的模块化 RAG 承载器

RAG 在请求链中的介入方式 ​

最常见的链路是：

  1. 接收用户问题
  2. 通过 Advisor 触发向量检索
  3. 将检索结果拼接到当前请求中
  4. 再发给模型生成答案

RetrievalAugmentationAdvisor 更进一步，把链路拆成：

  • Pre-Retrieval：查询改写、压缩、扩展
  • Retrieval：检索
  • Post-Retrieval：重排、去噪、压缩
  • Generation：带着处理后的证据去生成

高频边界 ​

  • RAG 不等于上下文工程的全部，它只是上下文来源之一
  • 检索不是越多越好，噪声过大反而伤效果
  • Query Transformer 这类预检索链路如果温度太高，容易把查询改写坏

3. 项目口径：在我的项目里怎么落地？ ​

在我的 [[苍穹外卖AI客服]] 项目里，RAG 主要承担 FAQ 和业务规则补给，而不是兜底所有问题。我会优先区分两类场景：

  1. 高频 FAQ 类问题

    • 先走本地语义缓存
    • 命中就短路，不再走 RAG 和 LLM

  2. 需要外部业务规则支撑的问题

    • 再由 RAG 补充文档、规则、知识库证据

我对 Spring AI 与 RAG 的理解不是“框架帮我接了向量库就结束”，而是它给了我一个很好的承载层，让我能把检索增强织入 Advisor 链里，再和记忆、工具白名单、安全拦截一起协同工作。最终效果好不好，关键还是你怎么控制检索噪声、怎么排序上下文、怎么决定哪些场景该进 RAG，哪些场景该走缓存或直接工具。

相关链接：[[上下文工程]] | [[Spring AI Advisor 链]] | [[Spring AI 与我的项目]] | [[苍穹外卖AI客服]] | [[RAG 检索架构]]